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Abstract — We  present  a  system  of  two  aircraft,  one  human- 
piloted  and  one  autonomous,  that  must  coordinate  to  achieve 
tasks.  The  vehicles  communicate  over  two  data  channels,  one 
high  rate  link  for  state  data  transfer  and  one  low  rate  link  for 
command  messages.  We  analyze  the  operation  of  the  system 
when  the  high  rate  link  fails  and  the  aircraft  must  use  the 
low  rate  link  to  execute  a  safe  “lost  wingman”  procedure  to 
increase  separation  and  re-acquire  contact.  In  particular,  the 
protocol  is  encoded  in  CCL,  the  Computation  and  Control 
Language,  and  analyzed  using  temporal  logic.  A  portion  of 
the  verified  code  is  then  used  to  command  the  unmanned 
aircraft,  while  on  the  human-piloted  craft  the  protocol  takes 
the  form  of  detailed  flight  procedures.  An  overview  of  the 
implementation  for  a  June,  2004  flight  test  is  also  presented. 

I.  INTRODUCTION 

In  modem  autonomous  systems  such  as  Uninhabited 
Aerial  Vehicles  (UAV’s),  the  implementation  of  the  com¬ 
mand  and  control  code  is  an  integral  part  of  the  control 
system  and  as  such  needs  to  be  analyzed  as  part  of  the 
system.  Control  algorithms  and  decision  logic  are  often 
designed  and  analyzed  using  one  set  of  tools  (i.e.  hybrid 
systems  theory)  and  then  implemented  in  a  language  such 
as  C/C++  that  may  not  be  well-suited  to  analysis.  At  some 
point  in  this  process  a  “leap  of  faith”  is  required  to  believe 
that  the  real  system  actually  implements  the  system  as  ana¬ 
lyzed.  As  these  systems  become  more  complex  and  operate 
in  more  uncertain  environments  it  is  becoming  increasingly 
desirable  to  narrow  or  eliminate  the  gap  between  algorithms 
as  analyzed  and  software  as  implemented  and  thus  reduce 
this  leap  of  faith.  An  appropriate  analytical  framework 
is  needed  to  consider  these  problems,  particularly  in  the 
context  of  understanding  behavior  under  failures. 

To  demonstrate  a  method  for  approaching  these  tasks, 
we  use  the  Computation  and  Control  Language  (CCL)  to 
analyze  a  realistic  example  problem,  that  of  the  operation 
of  a  UAV  as  a  “reliable  wingman”  in  conjunction  with  a 
human-piloted  craft.  We  envision  a  scenario  in  which  a 
human-piloted  lead  aircraft  and  an  autonomous  following 
aircraft  must  operate  in  concert,  flying  in  formation  to 
achieve  some  objective.  To  coordinate  their  actions  the 
aircraft  share  two  data  channels:  a  high-rate  link  for  the 
exchange  of  state  information  and  a  low-rate  link  along 
which  they  can  pass  more  limited  data.  In  an  analogy  to 
fully  human  flight,  the  high-rate  link  is  the  visual  contact 
the  pilots  share  and  the  low-rate  link  is  the  radio  voice 
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Fig.  1.  Lost  wingman  scenario.  At  point  (a)  aircraft  are  flying  in 
formation.  At  (b)  the  data  link  is  lost  and  the  UAV  begins  executing  the 
lost  winman  maneuver.  At  (c)  the  UAV  receives  a  confirmation  message 
from  the  leader  and  turns  to  match  heading.  At  (d)  the  data  link  is  restored 
and  at  (e)  normal  operation  resumes. 

communications  channel.  We  analyze  the  situation  shown 
in  Fig.  1  in  which  the  high-rate  link  is  lost  and  the  aircraft 
must  coordinate  using  the  low-rate  link  to  achieve  a  safe 
separation  in  absense  of  detailed  shared  state  information. 

CCL  is  a  specification  and  implementation  language 
for  the  operation  of  concurrent  systems  that  interact  both 
through  dynamics  and  logical  protocols.  The  advantages  of 
this  approach  are  several: 

•  The  formalism  of  CCL  and  the  analysis  techniques 
allow  us  to  analyze  the  dynamical  behavior  and  the 
logical  behavior  each  in  an  environment  naturally 
suited  to  them. 

•  CCL  is  both  a  specification  and  implementation  lan¬ 
guage,  meaning  that  the  protocols  we  analyze  and  the 
code  we  implement  are  nearly  identical;  in  come  cases 
they  are  one  and  the  same. 

•  Reasoning  about  CCL  specifications  is  done  using 
standard  logical  tools  amenable  to  the  application  of 
automated  theorem  proving  software. 

•  We  can  model  and  reason  about  portions  of  the  system 
using  CCL  specifications  even  if  they  will  not  be 
implemented  as  such. 

This  example  will  culminate  with  a  flight  experiment  in 
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June,  2004  in  which  a  human-piloted  F15  fighter  aircraft 
will  lead  an  autonomous  T33  UAV  surrogate  in  a  formation 
flight  exercise.  The  T33  will  simulate  loss  of  the  state 
exchange  data  link  and  the  lost  wingman  protocol  will  be 
tested.  Section  VI  provides  an  overview  of  this  implemen¬ 
tation. 

A.  Related  Work 

CCL  and  the  analysis  techniques  presented  here  were 
inspired  by  UNITY  [1]  and  applications  of  such  ideas 
to  real-time  systems.  The  UNITY  formalism  is  used  to 
specify  and  reason  about  concurrent  reactive  systems  [2], 
but  the  application  of  UNITY-like  formalisms  to  dynamic 
control  problems  has  not  been  well-developed.  Temporal 
logic  has  been  used  to  specify  and  reason  about  concurrent 
and  distributed  systems  [3];  with  CCL  we  extend  this  to 
include  an  implementation  language. 

Provably  safe  conflict  resolution  between  aircraft  has 
been  extensively  studied  in  the  context  of  air-traffic  control 
[4],  [5].  The  distinction  here  is  that  in  addition  to  verifying 
the  safety  of  the  lost  wingman  maneuver,  we  reason  about 
the  operation  of  the  underlying  decision  mechanism  (the 
software)  to  ensure  that  the  assumptions  behind  the  conflict 
resolution  safety  proofs  are  correct. 

A  great  deal  of  work  exists  on  formation  flight  [6], 
[7]  and  high-performance  maneuvering  [8]  of  autonomous 
aircraft.  We  are  interested  in  the  provably  correct  and  safe 
implementation  of  such  systems,  especially  in  the  presence 
of  faults,  requiring  an  examination  of  the  low-level  software 
in  addition  to  the  algorithm  specification. 

II.  CCL:  THE  COMPUTATION  AND  CONTROL 
LANGUAGE 

In  this  paper  we  use  CCL  as  both  a  modeling  environ¬ 
ment  for  the  complete  system  and  as  our  implementation 
language  for  a  portion  of  the  software.  We  summarize  here 
a  few  important  points  about  CCL;  this  material  has  been 
described  in  considerably  more  detail  in  previous  work  [9], 
[10]. 

A.  Structure  and  Semantics  of  a  CCL  Specification 

A  CCL  specification,  or  program ,  P  consists  of  two 
parts  I  and  C.  I  is  a  predicate  on  states  called  the  initial 
condition.  C  is  a  set  of  guarded  commands  of  the  form 
g  :  r  where  g  is  a  predicate  on  states  and  r  is  a  relation 
on  states.  In  a  rule,  primed  variables  (such  as  x'f)  refer  to 
the  new  state  and  unprimed  variables  to  the  old  state.  For 
example, 

x  <  0  :  x'  >  y  +  l 

is  a  guarded  command  stating:  If  x  is  less  than  zero,  then 
set  the  new  value  of  x  to  be  greater  than  the  current  value 
of  y  plus  1.  If  a:  is  not  less  than  zero,  do  nothing. 

Programs  are  composed  in  a  straightforward  manner: 
If  px  =  (I^C i)  and  P2  =  (72,C2)  then  P±  o  P2  = 
(Ji  A  72,Ci  U  Cf).  This  type  of  composition  allows  us 
to  modularize  our  specifications  into  separate  programs 


such  as  one  for  a  finite  state  machine  and  one  to  model 
the  dynamics.  In  an  real  system,  then,  we  can  implement 
only  the  state  machine  and  as  long  as  the  real  dynamics 
satisfy  the  CCL  specification  any  proofs  about  the  original 
specification  will  remain  valid. 

In  addition  to  the  initial  condition  and  the  collection 
of  guarded  commands,  we  need  to  specify  the  semantics 
we  will  use  to  interpret  the  specification.  The  semantics 
determine  how  commands  are  picked  for  execution,  i.e.  in 
what  order  and  with  what  relative  frequency.  In  general 
commands  are  picked  in  a  nondeterministic  way  to  model 
the  uncertainty  in  how  they  may  be  interleaved  in  the  actual 
system;  the  semantics  we  choose  place  restrictions  on  this 
nondeterminism.  For  the  purposes  of  this  paper,  where  the 
commands  are  picked  at  very  close  to  the  same  rate,  the 
EPOCH  semantics  will  be  sufficient.  Informally  EPOCH 
semantics  can  be  described  as  follows: 

CCL  EPOCH  Semantics:  Commands  are  chosen 
non-deterministically  from  C,  but  each  command 
must  be  chosen  once  before  any  command  is 
chosen  again. 

Thus,  the  execution  of  a  system  is  divided  into  epochs 
during  which  each  command  is  executed  exactly  once.  This 
is  an  attempt  to  capture  the  small-time  interleaving  that  may 
occur  between  processors  that  are  essentially  synchronized, 
as  well  as  the  nondeterministic  ordering  of  commands 
that  can  occur  when  some  are  picked  by  some  event- 
driven  process  while  others  are  picked  by  a  deterministic 
process.  We  generally  view  epochs  as  occurring  at  some 
fixed  frequency,  although  that  has  not  yet  been  explicitly 
modelled.  In  Section  III-A  we  discuss  one  way  to  include 
time  in  our  specification. 

The  EPOCH  semantics  are  just  one  of  several  interpre¬ 
tations  of  CCL  that  we  are  exploring.  Other  possibilities 
are  that  each  command  executes  at  approximately  the  same 
frequency  or  each  command  executes  equally  many  times 
in  any  interval;  these  may  be  more  appropriate  when  the 
specification  under  consideration  is  executing  across  multi¬ 
ple  processors  or  agents. 

B.  Implementation  of  CCL  Specifications 

While  we  may  reason  about  specifications  in  which  the 
rules  are  abritrary  relations  on  states,  any  code  we  write  will 
be  deterministic,  meaning  that  all  rules  will  be  assignments. 
In  this  case  there  exists  a  CCL  interpreter  known  as  CCLi 
[10],  [11]  that  can  be  used  to  execute  CCL  code.  The 
implementation  code  for  all  of  the  programs  described  here 
is  available  online  [12], 

C.  Reasoning  about  CCL  Specifications 

We  present  here  a  brief  overview  of  the  formalism  used 
to  reason  about  CCL  specifications,  described  in  more  detail 
in  previous  work  [9],  The  definitions  of  state,  state  function, 
action,  and  behavior  are  taken  from  [3], 


1 )  States,  Variables,  and  Actions:  We  begin  with  a  set  V 
of  variable  symbols  and  a  set  val  of  values  that  the  variables 
may  take  (natural  numbers,  real  numbers,  sets,  etc.).  A  state 
s  is  a  function  from  V  to  val,  and  the  set  of  all  states  is 
denoted  S.  The  value  of  a  variable  v  G  V  with  respect  to  a 
state  s  is  denoted  s[z;].  A  state  function  /  is  an  expression 
over  symbols  in  V  and  constant  symbols.  The  meaning  of 
a  state  function  /,  denoted  [/],  is  a  function  from  states 
into  values  and  is  defined  by 

si/]  =  /(Vf  :  /  v), 

that  is,  the  value  obtained  by  replacing  all  (free  occurrences 
of)  variables  in  /  by  their  values  under  the  state  s.  A 
predicate  is  simply  a  boolean  valued  state  function. 

We  denote  by  V'  the  set  {V  :  v  G  V},  that  is,  the 
set  of  all  primed  variables  symbols  from  V.  An  action  is 
a  boolean  valued  expression  over  variables  in  V,  primed 
variables  in  V'  and  constant  symbols.  The  meaning  of  an 
action  a,  denoted  [a],  is  a  function  from  S  x  S  into  values 
and  is  defined  by 

s[a]t  =  a(Vv  :  s[u]  /  v,  f[it]  /  v'), 

that  is,  the  value  obtained  by  replacing  all  unprimed  vari¬ 
ables  in  a  by  their  values  under  the  state  s  and  replacing 
all  primed  variables  in  a  by  their  values  under  t.  Note  that 
we  generally  regard  variables  not  appearing  primed  in  an 
action  as  not  changing.  A  guarded  command  is  simply  a 
particular  kind  of  action.  For  technical  reasons  we  also 
allow  the  action  skip  in  which  no  values  are  altered. 

We  will  need  to  reason  about  the  effect  of  an  action  on 
the  set  of  all  states  satisfying  a  predicate.  For  this,  we  use 
the  Hoare  triple  notation  (standard  in  Computer  Science). 
If  P  and  Q  are  predicates  and  a  an  action,  the  Hoare  triple 
relating  P  to  Q  by  a  is  defined  in  CCL  as 

{P}a{Q}  =  Vs,  t  .  sfP]  A  s[a]f  =>  f|Q], 

2 )  Behaviors  and  Temporal  Logic:  A  behavior  o  :  N  — » 
S'  of  a  program  P  =  (/,  C)  is  a  sequence  of  states  such  that 
er(0)[/]  and  there  exists  a  sequence  {ci}JY0  of  commands 
in  C  satisfying  the  semantics  of  P  such  that  <r(fc)[cfc]cr(fc  + 
!)• 

We  reason  about  entire  CCL  programs  using  standard 
temporal  logic  [13],  [3],  which  we  summarize  here.  Briefly, 
temporal  logic  formulas  are  constructed  from  predicates, 
actions,  basic  connectives  (such  as  V,  A,  -i  and  =>)  and  the 
special  operators  □  (always)  and  0  (eventually).  Given  a 
temporal  logic  formula  F,  we  define  [P]  to  be  a  function 
from  behaviors  to  {true,  false}  and  say  that  a  state  s 
satisfies  F  if  s[P],  If  p  is  a  predicate,  a  an  action,  and 
F  a  temporal  logic  formulas,  then 

1)  CT  |p]  =  cr(0)D>], 

2)  alDFj  4Vn.(a„,a„+1,...)[F]. 

The  formula  OP  is  equivalent  to  -ilU-iP.  We  also  find  the 
co  operator,  similar  to  one  introduced  in  [1]  and  [2],  to  be 
useful.  If  p  and  q  are  predicates,  then 

p  co  q  =  □  (p  =>  [((/  V  skip )  A  Of/]) 


Thus,  p  co  q  (read  “p  constrains  q”)  means  that  whenever 
p  is  true,  then  after  the  next  time  the  state  changes,  q  will 
be  true. 

We  will  generally  be  interested  in  when  all  possible 
behaviors  allowed  by  a  program  P  and  its  accompanying 
semantics  M  satisfy  a  temporal  logic  formula  F.  If  this  is 
the  case  we  write 

P  \=m  F, 

which  we  read  “P  models  P  under  M.”  If  this  property 
is  true  for  the  UNITY  semantics  (which  require  only  that 
all  commands  are  chosen  infinitely  often),  we  simply  write 
P  |=  P. 

D.  Dynamics  and  Time 

When  reasoning  about  a  real-time  system  it  will  be  nec¬ 
essary  to  keep  track  of  time  and  update  the  dynamics.  We 
can  accomplish  these  tasks  simultaneously  with  a  program 
that  updates  the  state  according  to  a  discrete  model  of  the 
dynamics  of  the  system  and  increments  the  time.  Consider 
a  general  control  system 

q  =  /(q.u),  (i) 

where  q  G  Q,  u  G  U,  and  assume  that  the  control  u  is  held 
constant  over  time  intervals  At.  Let  :  Q  x  U  — >  Q  be 
the  map  of  the  dynamics  through  time  At.  To  model  the 
flow  of  time  we  keep  track  of  two  variables,  the  current 
time  t  and  the  time  of  the  next  state  update  tn.  Each  time 
we  update  the  dynamics  using  <1»^,  we  set  the  current  time 
to  tn  and  increment  tn  by  At.  As  a  specification  for  a  CCL 
program,  we  have 

Program  Pdyn{t0,  At) _ 

Initial  q  G  Q  A  u  €  M  A  f  =  f0  A  fn  =  f0  +  Af 

Commands  true  :  q'  =  $At(q,  u) 

At'  =  tn 
/\t'n  =  tn  +  At 

Now  to  model  the  facts  that  each  command  takes  some 
time  to  execute  and  there  may  be  time  in  between  the 
execution  of  the  commands,  we  append  the  rule  t'  G  (t,  tn) 
to  each  rule  of  the  system  (for  space  reasons  we  omit  this 
from  the  specifications  in  the  remainder  of  the  paper  and 
assume  it  is  present).  If  we  wish  to  bound  the  amount  of 
time  any  command  may  take  by  St,  we  can  refine  this  rule 
to  obtain  t'  G  (t,  tn)  D  (t,t  +  St).  Assuming  no  other  rules 
modify  t  or  tn,  we  have  the  following  property: 

Proposition  1:  Let  Q  =  ( Iq,Cq )  be  any  program  such 
that  for  all  commands  cq  G  Cq  and  any  states  Si  and  s-i, 
si[cg]s2  =>  s\\t'n  =  tnf\t'  G  [t,  t„)]s2.  That  is,  a  command 
cq  may  not  modify  /  ,,  and  may  only  modify  t  by  a  rule  that 
implies  t'  G  [t,tn).  Let  P1  =  (. I,C )  =  Pdyn(t0,At)oQ. 
Then 

Pi  |=  D(tn  -At<t<  tn). 


Proof:  Let  II  =  (tn  —  At  <  t  <  tn)  be  the  property 
in  question.  Let  c  €  C  be  any  command  and  let  si  and  s2 
be  any  two  states  such  that  si[c]s2.  We  proceed  by  cases 
to  show  that  {n}c{II}: 

1)  Si[c]s2  =>  Si\t'n  =  tnAt'  =  f]s2: 

In  this  case  {n}c{II}  trivially. 

2)  si[c]s2  =>  si \t'n  =  tn  At'  £  [t,tn)]s2: 

First  Si\t'n  =  tn}s2,  so  Si[II]  =>■  s2[f  <  tnj.  We  have 
Si  \t'  >  I]s2  by  assumption  and  si[II]  =>  si[t  > 
tn  —  Af],  so  si|L  >  tn  —  Af]s2.  Then  also  s\\t'  > 
t'n  —  Af]s2  or  simply  s2\b  >  tn  —  At].  Finally  we 
have  s2\tn  —  At  <t  <  tn],  or  equivalently  S2[II]  so 

{n}c{n}. 

3)  si[c]s2  =>  silt'  =  tnAt'n  =  tn  +  At]s2: 

By  simple  algebra  s2ft  =  tn  —  At],  so  s2|II] 
regardless  of  si  and  {II}c{II}. 

By  assumption  on  the  commands  of  Q  we  have  covered 
all  possible  commands,  so  for  all  c  €  C  we  have  {n}c{II}. 
By  Lemma  5.2  of  [9]  then  P  |=  II  co  II.  By  the  Initial 
section  of  Pdyn  we  see  that  /  =>■  11.  Then  by  Lemma  5.3 
of  [9]  we  have  P  \=  Dll,  the  desired  result.  ■ 

III.  SYSTEM  DESCRIPTION 

We  now  turn  to  the  task  of  specifying  the  demonstration 
system.  This  system  consists  of  two  aircraft,  a  human- 
piloted  FI 5  fighter  and  an  autonomous  T33  jet  trainer 
serving  as  a  UAV  surrogate. 

A.  Dynamics  and  Semantics 

We  will  first  describe  the  dynamics  of  the  aircraft  in 
continuous  time,  then  using  the  technique  outlined  in 
Section  II-D  we  will  convert  this  description  to  a  CCL 
specification  and  accompanying  semantics.  We  use  a  simple 
planar  kinematic  model  to  describe  each  aircraft, 

X  =  V  cos  Ip, 

y  =  vsinip,  (2) 

where  ( x ,  y)  £  R2  is  the  position  of  the  vehicle,  v  £  R+  is 
the  speed,  and  if)  £  S1  is  the  heading.  For  the  vehicles  we 
analyze,  inner-loop  controllers  regulate  the  dynamics  and 
we  can  assume  outer-loop  actuation  of  the  form 

ip  =  Ui, 

v  =  u2.  (3) 

Thus  q  =  ( x ,  y,  ip,  v )  and  Q  =  R2  x  S1  x  R+. 

We  assume  that  the  aircraft  share  similar  performance 
charactaristics.  While  this  may  not  be  the  case  in  practice 
(for  example,  an  F15  has  dramatically  higher  capabilities 
than  a  T33),  it  will  be  necessary  to  limit  the  performance 
of  one  aircraft  to  suit  the  other  in  order  to  safely  fly  in 
formation.  In  fact,  it  may  often  be  most  realistic  to  think  of 
the  performance  limit  as  imposed  by  operating  procedures 


rather  than  physical  limitations.  Let  the  maximum  turn  rate 
be  ipmax  and  the  maximum  acceleration  be  vmax  so  that 

IA  =  {(u\,U2)  !  Ipmax  A  tti  A  tpmaxi 

t^max  A  1^2  A  Xrnaxy. 

Using  the  technique  described  in  Section  II-D,  we  specify 
two  programs,  Fdyn  and  Tdyn,  to  keep  track  of  the  dynamics 
of  the  F15  and  T33,  respectively,  using  the  subscript  1  to 
denote  the  FI 5  (so  for  example  the  position  of  the  FI 5 
is  (xi,yi))  and  2  to  denote  the  T33.  We  also  constrain  the 
execution  to  obey  the  EPOCH  semantics,  with  the  additional 
requirement  that  each  epoch  begin  with  the  execution  of  the 
command  describing  the  dynamics.  In  the  actual  system  the 
execution  of  each  epoch  is  triggered  by  an  accurate  software 
timer  every  At  seconds  and  each  epoch  will  complete 
before  the  next  trigger,  so  this  is  a  realistic  model. 

B.  Controllers 

Each  aircraft  runs  a  controller  that  at  each  update  uses 
its  own  data  plus  what  is  known  about  the  other  aircraft  to 
generate  controls  u.  We  envision  that  this  is  accomplished 
by  some  function  control  :  Q  x  Q  — >  U  that  we  will  leave 
unspecified  aside  from  assumptions  about  safety  properties 
to  be  defined  later.  This  allows  us  to  use  any  number  of 
control  techniques  in  the  system  to  be  implemented  while 
retaining  the  correctness  of  the  safety  proofs,  provided  the 
implemented  controller  satisfies  the  safety  specification. 

Program  Pc 

Initial  u  =  (0, 0) 

Commands  true  :  u'  =  control(xi,x2) 

As  with  the  dynamics  we  denote  the  F15  controller  by 
Fc  and  the  T33  controller  by  Tc. 

C.  Formation  Flight 

Under  normal  operation  the  two  aircraft  will  be  flying  in 
formation  with  one  another,  with  the  FI 5  as  a  leader  and 
the  T33  as  a  follower.  This  can  be  specified  by  creating  a 
coordinate  system  with  the  origin  at  the  F15  and  the  x-axis 
oriented  with  the  F15.  We  then  require  that  the  T33  remain 
within  a  ball  of  radius  d  of  some  desired  tracking  point 
(2:0 , 2/o )  and  with  an  orientation  within  Sip  of  that  of  the 
F15. 

D.  Communication 

We  suppose  there  are  two  communications  links  between 
the  two  aircraft,  a  “high-speed”  data  connection  for  state 
information  and  a  less  freqently  used  “low-speed”  connec¬ 
tion.  The  high-speed  link  is  implemented  by  the  lower- 
level  command  and  control  software,  and  because  the  CCL 
program  on  the  T33  interacts  with  this  subsystem  only 
to  check  if  new  data  have  arrived  we  abstract  it  into  a 
command  Cdat.a  that  updates  Ts,  the  next  time  data  will 
be  sent  by  the  F15,  and  T,  the  next  time  data  will  be 
received  by  the  T33.  The  send  time  Ts  is  incremented  by 


AT  whenever  data  are  sent,  reflecting  the  fact  that  the  F15 
sends  data  at  a  regular  rate,  while  the  receive  time  T  can  be 
anything  in  the  interval  (Ts,  Ts+Td],  reflecting  the  uncertain 
time  delay  in  the  system.  We  keep  track  of  the  status  of  the 
data  link  using  the  boolean  variable  data-on. 

We  model  the  low-speed  communications  link  using  a 
mailbox  with  a  queue  and  a  nondeterministic  time  delay 
of  up  to  tc.  When  a  message  is  sent,  a  record  is  added  to 
the  end  of  the  queue  containing  a  scheduled  arrival  time 
ta  G  (t,t  +  tc].  We  write  send(i,y)  as  shorthand  for 

t'a  £  (M  +  tc] 

A  queued  =  queueiff[data  =  y,ta  =  t'a], 

where  #  is  infix  notation  for  concatenation  of  an  element 
to  the  end  of  a  list  and  i  is  the  index  of  the  mailbox.  We 
then  have  the  predicate  in(i)  which  is  true  if  a  message 
has  arrived: 

in(i)  =  t>  ( head  queuefj.ta- 

As  will  be  seen  below,  the  nature  of  the  messages  we  send  is 
such  that  we  are  only  interested  in  the  most  recent  message 
received.  We  use  msg'  =  recv(i )  to  denote  setting  the  new 
value  of  msg  to  the  data  field  of  the  most  recent  record 
in  queuei  for  which  t  >  ta  and  then  deleting  from  queuei 
all  messages  for  which  t  >ta.  We  use  the  index  1  for  the 
mailbox  of  the  F15  and  2  for  the  mailbox  of  the  T33. 

All  of  these  communications  are  specified  by  the  program 
P 

1  comm • 

Program  Peomm _ 

Initial  Ts  =  to  AT  £  (Ts,Ta  +  AT] 

Commands  Cdata  =  t  >  T  A  datajon  : 

T'  £  (Ts  +  AT,  Ts  + AT  +  rd] 
A  T's  =TS  + AT 

Cmsg,i  =  in(  1)  :  msg[  =  recv(  1) 

Cmsg, 2  =  in( 2)  :  msg'2  =  recv( 2) 

IV.  LOST  WINGMAN  PROTOCOL 

The  lost  wingman  protocol  consists  of  two  parts:  a 
CCL  state  machine  managing  the  T33  and  a  detailed  flight 
procedure  for  the  pilot  of  the  F15.  The  flight  procedure  can 
also  be  written  as  a  state  machine,  and  so  for  purposes  of 
analysis  we  can  model  the  pilot’s  behavior  using  CCL  as 
well. 

A.  T33 

The  state  machine  running  on  the  T33  is  depicted  in  Fig. 

2.  The  system  has  four  modes  denoted  by  the  variable  m2 
in  the  programs: 

•  normal ,  for  normal  formation  flight,  abbreviated  n 

•  losti,  for  the  case  where  the  T33  has  ceased  receiving 
state  data  from  the  F15  and  has  not  yet  received  a 
confirmation  of  lost  status,  abbreviated  1 1, 

•  lost2,  for  the  case  where  lost  confirmation  has  been 
received  from  the  F15,  abbreviated  l2,  and 


Fig.  2.  T33  state  machine. 


•  found,  for  the  case  where  the  state  data  link  has 
been  reacquired  but  normal  formation  flight  has  not 
resumed,  abbreviated  f. 

In  this  paper  we  will  examine  what  happens  when  the 
T33  enters  losti  mode  from  normal  mode.  The  portion 
of  the  state  machine  specification  involving  this  portion  of 
operation  is: 


Program  Tsm 


Initial 

777,2  =  n 

Commands 

C-lost 

m2  G  {n,  /}  A  t  —  T  >  AT  +  rd 
™>2  =  h  A  t'lost  =  t 

Asend(\,  “lost”) 

C found  — 

m2  G  {h,h}  A  t  —  T  <  AT  +  rd 
m'2  =  f 

Clost2  — 

m2  =  h  A  msg2-m  =  “lost”  : 
m'2  =  h  A  v'ref  =  msg2-v 

A  ip'ref  =  msg2.ip 

1 )  Normal  mode:  In  normal  mode  the  aircraft  are  in 
a  formation  flight  condition.  The  only  transition  out  of 
normal  mode  is  to  losti  mode,  which  occurrs  when  F15 
data  has  not  been  received  by  the  latest  expected  arrival 
time,  i.e.  when  t  —  T  >  AT  +  Td.  In  this  mode  we  place 
the  formation  flight  requirement  on  the  T33  controller.  Let 
(x,  y,  ip)  be  the  position  and  orientation  of  the  T33  relative 
to  a  coordinate  system  centered  at  the  desired  tracking  point 
with  the  x-axis  in  the  direction  of  the  F15’s  orientation.  We 
then  require 

Tdyn  0  F'e  °  -L/yn  0  Tc  O  Pcornrn  |=  E  POCH 

□  (m2  =  n  =>  ||(x,  j/)||2  <  d  A  \ip\  <  Sip).  (4) 

We  see  here  how  CCL  lets  us  abstract  portions  of  the 
problem  into  specifications  that  can  be  reasoned  about 
separately.  We  can  use  tools  from  control  theory  to  show 
that  a  pair  of  controllers  meet  the  above  specification  and 
then  use  the  results  derived  below  to  show  safety  of  the 
complete  system. 


2)  Lost  1  mode:  In  lost i  mode,  the  T33  has  ceased 
receiving  state  information  from  the  FI 5.  In  this  mode  it 
commands  the  controller  to  execute  a  pre-specified  open- 
loop  escape  maneuver.  Transitions  out  of  this  mode  are  to 
the  found  mode,  if  state  data  is  reacquired,  or  to  lost2 
mode,  if  an  acknowledgement  message  is  received  from  the 
F15. 

3)  Lost  2  mode:  In  lost2  mode  the  T33  has  received  a 
messsage  from  the  F15  that  acknowledges  the  lost  wingman 
status  and  includes  a  reference  speed  vref  and  heading 
ipref  ■  The  software  then  commands  the  controller  to  track 
these  references.  The  transition  out  of  this  mode  is  to  found 
mode  when  state  data  is  reacquired. 

4)  Found  mode:  In  found  mode  the  T33  has  reaquired 
the  state  data  link  and  will  command  the  controller  to 
maintain  a  safe  distance  from  the  F15.  The  T33  will  then 
periodically  send  a  message  to  the  F15  indicating  the  found 
status  and  thereby  requesting  to  rejoin  the  formation.  The 
transitions  out  of  this  state  are  back  to  losti  mode  if  data 
is  once  again  lost  or  to  normal  mode  if  the  F15  approves 
the  rejoin  request. 

B.  F15 

The  F15  state  machine  consists  of  just  two  modes  (de¬ 
noted  by  mi  in  the  specifications),  normal ,  for  normal 
formation  flight,  and  lost ,  for  the  lost  wingman  scenario. 
In  normal  mode  the  pilot  is  free  to  fly  at  will  within  a 
performance  envelope  that  ensures  safe  formation  flight  is 
possible.  If  the  pilot  receives  a  lost  message  from  the  T33, 
the  procedure  is  to  transition  to  straight  and  level  flight  and 
transmit  to  the  T33  the  resulting  speed  and  heading.  Upon 
receiving  and  acknowledging  a  rejoin  request  and  observing 
that  the  T33  has  rejoined  formation  safely,  the  pilot  can 
resume  normal  operation. 

V.  VERIFICATION 

We  constrain  the  CCL  software  on  the  T33  to  satisfy 
the  EPOCH  semantics,  and  further  require  that  each  epoch 
begin  with  the  execution  of  the  command  updating  the 
dynamics  and  time.  This  is  a  model  of  the  real  system 
in  which  the  execution  of  an  epoch  is  triggered  by  a 
software  timer.  We  then  have  a  simple  result  stating  that 
for  a  program  Pi  as  defined  in  Proposition  1  the  maximum 
increment  in  time  between  subsequent  executions  of  a  given 
command  is  less  than  2AZ: 

Proposition  2:  Let  a  be  any  behavior  of  Pi  and  let 
{ki}fl1  be  the  sequence  of  steps  at  which  a  command  c 
is  chosen  for  execution  (i.e.  cr”1(c)  taken  as  an  ordered 
list).  Then 

-  t  <  2AtJa(ki+1). 

Proof:  By  Proposition  1  we  know  that  cr(ki)\tn  — 
At  <  t  <  t„],  By  the  constraint  that  each  epoch  begin 
with  the  state  update  command  we  know  that  cr{k,)\tn  < 
t'  <  tn  +  Af]cr(fcj_|_i).  Together  this  gives  us  a(ki)ftn  — 


At  <  t  <  tn  A  tn  <  t'  <  tn  +  Af]<r(fc,+i),  which  implies 
a(ki)lt'  -  t  <  2Af]<r(fei+i).  ■ 

A  simple  corollary  is  that  for  any  time  t\  and  clause  c  there 
exists  a  k  such  that  a(k)ft  G  (fi  —  2Af,  t\)  A  c]er(fc  +  1). 

A.  Lost  Wingman  Scenario 

We  examine  here  a  bound  on  the  amount  of  time  since 
receipt  of  the  last  state  data  packet  it  takes  for  the  T33  to 
recognize  that  it  is  lost  and  enter  lost  mode. 

Proposition  3.  Let  P2  —  l  iiyn  o  Tsrn  ®  Pcomm  and  let  o 
be  a  behavior  of  P2.  Suppose  there  exists  a  k\  such  that 
cr{ki)\t  —  T>  AT  +  Td  +  2 At],  i.e.  the  time  is  more  than 
2At  greater  than  the  latest  possible  packet  arrival  time.  Then 
cr(A;1)[rn2  G  {(1,(2}]-  Formally, 

P2  | =epoch  D(t  —  T  >  AT  +  Td  +  2At  =>  m2  G  {Zi,  Z2}). 


Proof:  We  examine  the  command  ciost  =  giost  ■ 
riost  from  the  program  Tsm.  By  Proposition  2  there  exists 
a  k2  <  k±  such  that  a{kf)\t  >  t'  —  2Af]cr(fc1)  and 
rt(>2)[c;ost]cr(fc2  +  l),  that  is  the  clause  ciost  was  chosen  for 
execution  when  time  time  was  larger  than  <r(/ci)[t]  —  2At. 
Thus  CT(fc2)[f  —  T  >  AT  +  Td],  and  we  examine  the  two 
possible  cases  for  m2  when  ciost  was  chosen: 

1)  If  cr(fc2)|m2  G  {n,  /}]  then  a(k2)lgiosti  and  so 
cr(fc2  +  1  )[m2  =  hj. 

2)  If  cr(fc2)|?rt2  G  {Zi,Z2}]  then  a(k2)l^gios4  and  so 

(j{k2)\m'2  =  m2jcr(k2  +  1). 

Thus  we  see  that  {t  —  T  >  AT  +  Td\ccheck{m 2  £ 
{(1,(2}}-  Now  the  only  command  transitioning  out  of 
{Zi,  Z2}  is  c found,  which  has  as  part  of  its  guard  the  predicate 
t  —  T  <  AT  +  Td,  so  for  all  commands  c  G  C,  {t  —  T  > 
AT  +  rd  A  m2  G  {Zi,/2}}c{to2  G  {Z1;Z2}}.  Now  for  all 
/c3  £  [Zc2  +  1,  ki\  we  have  er(fc3)[f  —  T  >  AT  +  Td  A  m2  G 
{hMl  and  so  the  result  holds.  ■ 

It  will  be  impossible  to  prove  that  the  two  aircraft  can 
never  collide  if  the  F15  is  never  made  aware  that  the  T33 
is  in  a  lost  state.  Instead  we  will  need  to  reason  about  how 
soon  the  F15  receives  the  “lost”  message  and  responds  to  it 
and  ensure  that  the  aircraft  cannot  collide  within  that  time. 
Let  the  maximum  time  required  for  the  F15  to  roll  level  and 
send  a  reply  (thereby  entering  lost  mode)  after  receiving  a 
“lost”  message  be  rr.  The  following  proposition  then  gives 
us  a  bound  on  the  amount  of  time  between  the  T33  entering 
losti  mode  and  the  F15  entering  lost  mode: 

Proposition  4:  Let  k\  be  such  that  cr(ki)  is  the  state  im¬ 
mediately  after  the  T33  transitions  to  l\  mode,  so  <r(/ci)[f  > 
Zlosi]  and  cr(fci)[TO2  =  Zi],  Suppose  there  exists  /C2  >  k\ 
such  that  a(k,2)\t  >  tiost  +tc  +  rr]  and  for  all  k  G  [k\,  kf\ 
we  have  <7fc[TO2  G  {Zi,Z2}].  Then  cr(fc2)[mi  =  Z], 

Proof:  We  again  examine  c/ost,  and  see  that  the  T33 
sends  a  “lost”  message  when  it  transitions  to  Zi  mode.  The 
F15  receives  this  message  no  more  than  rc  seconds  later, 
and  itself  transitions  to  Z  mode  no  more  than  rr  seconds 


after  that  by  assumption.  Thus  at  some  point  in  the  interval 

( tioSt,  Uost  +  rc  +  Tr)  the  F15  enters  lost  mode,  or 

3k3  .  cr{k3)\t  G  (Uost,  Uost  +  Tc  +  Tr)  A  mi  =  lost}. 

Because  time  is  increasing,  i.e.  t  =  t\  co  t  >  t\,  we  see 
that  fc3  G  [ki,k2]- 

By  assumption  a(k)\m2  G  , Z2 }]  for  all  k  G  [k\,k2], 
and  so  in  particular  this  is  true  for  k3.  The  F15  only 
transitions  out  of  lost  mode  when  it  receives  a  “found” 
message  from  the  T33,  which  is  only  sent  when  the  T33 
transitions  to  found  mode,  so 

(m2  G  {losti,  lost2}  A  m2  =  lost)  co  m2  =  lost. 

Thus 


\/k  G  [k3,  k2 ]  .  <r(k)\m2  G  {lost\,  lost2}  A  m  1  =  lost} 

and  the  result  holds.  ■ 

Proposition  5:  Let  t„,  be  the  time  when  the  T33  receives 
a  “lost”  message  from  the  F15  and  ti2  be  the  time  when 
the  T33  transitions  to  l2  mode.  Then  ti2  —  tm  <  2A t. 

Proof:  The  proof  is  immediate  from  the  application 
of  Proposition  2.  ■ 


B.  Lost  Wingman  Dynamics 

In  this  section  we  use  the  underlying  continuous-time 
dynamics  of  the  aircraft  to  determine  bounds  on  the  po¬ 
sitions  of  the  aircraft  as  they  evolve  in  discrete-time.  Let 
T(x,y,ip,p)  be  the  cone  with  vertex  (x,  y)  oriented  in  the 
direction  ip  and  with  half-angle  p. 

Proposition  6:  Consider  an  aircraft  with  dynamics  given 
by  Pdym  where  is  the  map  of  (2)  and  (3)  through  time 
At,  and  let  er  be  a  behavior  of  Pdyn-  Then  for  any  r  >  0 
and  k\,k2. 


r(fci) 


t'  =  t  +  t  =>  (x1,  y')  G  T  x,  y ,  ip, 


tpr, 


y{k2) 


Proof:  Because  Pdyn  is  equivalent  to  a  discrete-time 
sampling  of  (2)  and  (3)  it  is  sufficient  to  show  that 


(x,y)(t  +  r)  G  F 


^x(t),y{t),ip(t), 


The  geometry  of  the  system  for  a  constant  turn  rate  ip  is 
shown  in  Fig.  3.  After  time  r  the  angle  A  ip  =  ip  —  ipo  is 
equal  to  ipr.  The  two  dotted  lines  in  the  figure  are  radii  of 
the  same  arc,  so  their  lengths  are  equal.  The  angle  7  is  then 
7T~^ ,  so  the  angle  ip  =  f  —  7  =  ^  This  angle 

will  be  maximized  for  ip  =  ip  max-  Thus  the  aircraft  must 
remain  inside  the  given  cone.  ■ 

Now  we  examine  a  sufficient  condition  that  guarantees 
the  aircraft  cannot  collide. 

Proposition  7:  Suppose  that  at  time  to  the  F15  is  located 
at  (0,  0)  with  orientation  in  the  +y  direction  and  the  T33 
is  within  a  ball  of  radius  D  of  the  point  ( Xo,yo ),  where 
|a;o  |  >  D  (so  the  T33  can  only  be  on  one  side  of  the  F15), 
with  orientation  equal  to  that  of  the  FI 5  and  at  this  time 


Fig.  3.  Geometry  of  Proposition  6.  The  aircraft  starts  at  the  lower-left 
comer  with  orientation  straight  up  and  turns  at  a  constant  rate  ip. 


the  T33  begins  executing  the  lost  wingman  maneuver  (set 
\ip\  =  ip max >  with  direction  away  from  the  FI 5).  Then  if 

tpmaxT  IpmaxT  , ,  .  ... 

y0  sin  — - - x0  cos  — - - b  D  <  0  (5) 

is  satisfied  for  all  0  <  r  <  t  —  to,  there  can  be  no  collision 
between  the  aircraft  before  time  t. 

Proof:  Assume  that  Xo  >  0;  the  rest  of  the  result 
follows  from  symmetry.  We  show  that  the  path  of  the 
T33  must  lie  behind  the  cone  defined  by  p  determined 
in  Proposition  6.  The  line  defined  by  p  can  be  written 
as  y  =  ta”  ,  with  points  behind  the  line  then  given  by 
y  <  taa  .  The  position  of  the  T33  when  t  —  to  =  r  is 
(x  +  -T-MpL  -  cos  ipmaXT),y  +  sin ipmaxT),  where 

Wmax  tymax 

(x,  y)  is  the  actual  starting  position  of  the  T33.  This  point 
is  behind  the  cone  boundary  if 


y  +  r  sin  if^ 


< 


x  +  r(l 


-  COS  IpmaxT ) 
tan  p 


Thus  if  this  inequality  is  satisfied  for  all  0  <  r  <  t  —  to, 
the  T33  is  always  outside  the  region  reachable  by  the 
F15  by  time  to-  The  worst  case  is  given  by  ( x,y )  = 
(xq  —  D  cos  p,  yo+D  sin  p).  Substituting  this  into  the  above 
inequality,  noting  from  Proposition  6  that  p  =  ^m|xT,  and 
applying  trigonometric  identities  yields  the  result.  ■ 

We  now  extend  this  result  to  the  case  where  the  T33’s 
initial  orientation  may  differ  from  that  of  the  F15. 

Proposition  8:  Suppose  that  at  time  to  the  T33  is  within 
a  ball  of  radius  d  of  the  point  (ato,  yo)-  where  |cco|  >  d,  with 
orientation  within  Sip  of  the  F15  and  at  this  time  the  T33 
begins  executing  the  appropriate  lost  wingman  maneuver. 
Then  if 


•  tpmax  Ipmax 

Vo  sin  — - - Xq  cos  — - — 


d  +  Sip 


Ip  7! 


2  -  2  COS  IpmaxT  <  0  (6) 


is  satisfied  for  all  0  <  r  <  t  —  to,  there  can  be  no  collision 
between  the  aircraft  before  time  t. 

Proof:  We  make  the  same  assumptions  as  in  Propo¬ 
sition  7.  Let  the  actual  position  of  the  T33  at  time  to 
be  ( x,y ).  If  the  orientation  matches  that  of  the  F15,  the 
position  at  time  t0  +  r  is  again  (x  +  r  (1  —  cos  ipmaxT) ,  y  + 
r  sinipmaxT)-  The  distance  between  this  point  and  ( x,y ) 


is  — y  2  —  2  cos  ipmaxT.  If  the  initial  orientation  is  per¬ 
turbed  by  Sip,  the  resulting  perturbation  in  the  final  position 

is  then  df  =  SipfA — \]^  —  2  cos  tpmaxT-  Thus  we  can 
bound  the  error  caused  by  perturbing  the  initial  orientation 
by  considering  it  instead  as  a  perturbation  of  df  in  the 
initial  condition.  The  total  effective  perturbation  in  initial 
condition  is  then  D  =  d  +  df.  Substituting  this  into  (5) 
yields  the  result.  ■ 

For  the  experimental  system,  v  =  150 m/s  and  ipmax  = 
0.1  rad/s.  If  the  T33  is  attempting  to  track  a  point  150m 
away  from  the  F15  and  |  radians  behind  it.  Proposition 
8  says  that  if  the  T33  begins  executing  the  lost  wingman 
procedure  while  within  a  5 m  radius  of  the  desired  operating 
point  and  within  5  degrees  of  alignment,  collision-free 
operation  is  guaranteed  for  11s. 

We  are  now  ready  to  attack  the  main  safety  result: 

Theorem  1:  Suppose  data  is  generated  at  the  F15  every 
AT  seconds  and  received  at  the  T33  with  maximum  la¬ 
tency  T(i.  Suppose  the  controller  is  such  that  under  normal 
operation,  if  a  final  packet  arrives  at  t  =  T,  then  at 
t  =  T  +  AT  +  Td  +  2 At  the  T33  is  within  a  ball  of  radius 
d  around  the  actual  desired  tracking  position  and  within  dip 
of  the  F15’s  orientation.  Then  if  the  condition  in  (6)  holds 
for  d  and  Sip  for  0  <  r  <  2Ai  +  2 rc  +  rr,  the  T33  will 
safely  pass  through  lost  mode  in  the  event  of  a  packet  loss. 

Proof:  If  a  packet  arrives  at  time  T,  the  next  packet 
is  expected  by  time  T  +  AT  +  t^.  If  this  packet  does  not 
arrive,  the  T33  will  enter  lost  mode  within  '2 At  seconds 
by  Proposition  3.  Thus  by  assumption  on  the  controller,  the 
T33  enters  lost  mode  while  within  a  ball  of  radius  d  of  the 
desired  tracking  point  and  Sip  of  the  orientation  of  the  F15. 
By  Proposition  4,  the  F15  will  send  a  “lost”  message  and 
transition  to  lost  mode  no  more  than  rc  +  ry  seconds  later. 
This  message  will  arrive  at  the  T33  after  no  more  than  rc 
seconds,  and  by  Proposition  5  the  T33  will  enter  lost.2  mode 
no  more  than  2 At  seconds  later.  The  total  time  between  the 
T33  entering  lost  mode  and  entering  lost.2  mode  is  then 
bounded  by  2A t  +  2 rc  +  Tr.  By  Proposition  8  the  T33  and 
the  F15  cannot  collide  within  this  time.  The  other  possible 
transition  out  of  lost\  mode  is  to  found  mode  if  new  data 
is  received;  if  this  transition  occurrs  within  this  time  then 
the  result  holds  trivially.  ■ 

VI.  EXPERIMENTAL  IMPLEMENTATION 

The  software  described  here  will  be  implemented  on  a 
F15  and  T33  testbed  for  a  flight  test  in  lune,  2004.  Low- 
level  control  aboard  the  T33  will  be  carried  out  within 
the  framework  of  Boeing’s  Open  Control  Platform  (OCP). 
The  OCP  will  also  incorporate  a  module  that  executes  a 
portion  of  the  verified  CCL  code  at  scheduled  intervals.  The 
program  Tsm  and  a  portion  of  Pcomm  will  be  implemented 
in  CCL,  while  the  other  programs  discussed  here  serve  as 
specifications  for  the  control  code  currently  under  develop¬ 
ment.  The  CCL  specifications  for  the  F15  will  provide  the 
basis  for  the  detailed  flight  procedures  given  to  the  pilot. 


VII.  CONCLUSIONS  AND  FUTURE  WORK 

The  results  given  by  Theorem  1  rely  on  very  conservative 
assumptions  about  when  a  collision  may  occur.  The  problem 
of  minimal  time  for  the  F15  and  the  T33  to  have  a 
possibility  of  collision  is  treated  more  precisely  by  the  two- 
car  problem  of  differential  game  theory  [14],  and  so  one 
avenue  of  future  work  is  to  apply  results  as  in  [4]  to  reduce 
this  conservatism. 

A  major  focus  of  future  work  will  be  developing  auto¬ 
mated  tools  for  the  design  and  analysis  of  CCL  specifica¬ 
tions.  Opportunities  include  the  development  of  a  graphical 
design  environment  for  state  machines  with  automated  CCL 
code  generation  and  the  use  of  automated  theorem  proving 
assistants  such  as  Isabelle  [15]  when  reasoning  about  speci¬ 
fications.  Such  tools  will  become  critically  important  as  the 
systems  we  analyze  become  more  complex. 
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